Subject: Elimination of LLC Connection in HPR

From: "jim (j.) cobban" <[email-masked]>
Date: Tue, 1 Aug 1995 16:42:00 -0400

Existing HPR implementations establish an LLC2 connection unconditionally.
This is described in chapter 6.1 which says "For link activation, DLCs are
used by HPR in the same manner as APPN.  That is XID3 is exchanged and the
appropriate set mode signals are sent when the exchange is complete".  HPR
nodes also exchange data using LLC1.  However if two adjacent HPR capable
nodes both support the Rapid Transport Protocol (RTP) tower and the Control
Flows over RTP tower, then only dependent LU traffic (without DLUR) uses the
LLC2 connection.  If there is no such traffic, then the LLC2 connection
(using the original SAP pair also used for the XID negotiation) carries NO
traffic.  See section 5.1 of the architecture for reference.  The HPR node
is required to establish an LLC2 connection which will exchange nothing but
RRs as long as it is up.  IBM then argues that HPR nodes must use a different
SAP pair for the UI exchange in order to improve the performance of the
traffic which is carried in the UIs, by distinguishing it at the earliest
opportunity from the non-existent traffic on the LLC2 pipe.  See section
6.2.2 for reference.

Note that support for the two function towers is signalled in the CV 61.  The
two nodes therefore KNOW that they are not going to exchange any I frames.
And yet they still establish the LLC2 connection and still may insist upon
using a different SAP for the LLC1 traffic.  Moreover if anything ever
happens to the LLC2 connection then the HPR pipe is taken down, even though
there would have been no traffic disruption.

If the requirement for establishing the LLC2 pipe were removed then the
maximum 255 LLC connection limit typical of most adapters is also eliminated.

Since in this situation it would be natural to use the same SAP pair for the
LLC1 data as for the XID connection, this data link transport could be
handled by the existing DLSw specification, where the use of different SAPs
for the UI traffic will cause HPR traffic to be improperly routed, if at all,
according to the current specification.

I therefore propose to the HPR SIG that the LLC2 connection be made
optional on LANs, Frame-Relay, and ATM in the case where the XID exchange
establishes that it is not necessary.  For backwards compatibility
suppressing the initiation of the LLC2 connection requires an explicit bit
in byte 2 of the CV 61.  

If an HPR station has both sent and received an XID with this bit, then
it does not establish the LLC2 connection and ignores the setting or default
value of subfield 80.  If either station does not recognize this configuration
and sends a SABME anyway, the other station responds with DM.

This proposal has an impact on the Configuration Services chapter of the APPN
Architecture Reference.  It is still necessary for CS to send a SET_MODE
signal to DLC, since most of the parameters in this signal are information
which the DLC still needs to have.  However this SET_MODE signal must also
indicate whether or not an actual LLC connection needs to be established.

---

From: Dave Finnie <[email-masked]>
Date: Wed, 2 Aug 1995 09:51:49 +1000

Jim,

I think it is a good idea to remove the LLC2 requirement for
HPR. There are a few minor things that we need to think about in
addition to your comments. The things that come to mind immediately
are:

 * There needs to be a "new" method to know when a link is up. Since
   no mode setting command is used, and CS logic requires one
   currently, we need some method to identify when the XID exchange is
   complete.

 * LLC2 does provide reliable delivery of XIDs for CS (although
   duplicates may occur if timer values are chosen
   inappropriately). This will no longer be the case. This, of course,
   applies to activation as well as non-activation flows.

 * Without having investigated it at all, I think some action may need
   to be taken to detect link outage. For links between nodes that
   have CP-CP sessions, the timeout of the CP-CP session could be used
   to determine if the link had timed out. However, CP-CP sessions may
   not be present (either through function (eg EN-EN), or
   configuration). So some non-CP-CP session based method of detecting
   link outage would be required.

Dave